Fluent Interfaces & Method Chaining
Hammett calls the term "Fluent Interface" unnecessary:
And about Fluent interfaces, what about OOP? What about method chaining? Does it need, for god’s sake, a new name?
This is method chaining:
string user = new StringBuilder() .Append("Name: ") .Append(user.Name) .AppendLine() .Append("Email: ") .Append(user.Email) .AppendLine() .ToString();
And this is a fluent interface:
return new Finder<Order>( Where.Order.User == CurrentUser && ( Where.Order.TotalCost > Money.Dollars(150) || Where.Order.OrderLines.Count > 15 ), OrderBy.Order.CreatedAt ).List();
Anders posts about DSL building contains examples that are tied more closely to the domain.
Method chaining is something that you would certainly use in the a fluent interface, but that is like saying that you need to use interfaces when you build a plugin framework. The fact that you are using something doesn't mean that what you do is only that something.
Fluent interfaces are different than merely method chaining because they allow you to express your intent in the domain terms and allows you to get more readable code. Method chaining, operator overloading, nasty generics tricks are all part of that, certainly, but the end result is much more than just a simple method chain.
And yes, I think that it certainly deserves its own name.
Comments
Having recently worked on creating a so called fluent interface I can definately say it is alot more than method chaining.
Method chaining is to fluent interfaces :: hammering nails is to building a wall
I think it deserves it's own name as well.
I vote for “Comprehensible Interface”
I think Hammett was having a bad day ... a very unusual outburst :)
I can see where he might come from, Martin does have the odd attempt at redefining things to suit him better, and some people take his stuff as gospel a little too easily. But overall, I'm pretty sure Martin is a force for good rather than evil :)
Jealousy, perhaps.
I don't know, I've studied the idea, thought about fluency for a system or two -- where there is the possibility for a bit of evolution beyond chaining and for greater DSL-ness -- and it still strikes me as more "cute-sy" than vital... From everyone I've shown it to, the response has been more 'aha' than 'Aha!!' Hard to get traction, unless someone else gets smitten with the idea.
I'd love to see someone make The Case for fluent interfaces, to show the quintessential example that makes this design pattern worthy of entry into the canon (not the kludgey SQL/XQuery/LINQ exemplar that's everywhere, which just makes the subject more confusing). Because make no mistake, this a heavyweight design pattern.
I'm willing to be converted, though.
Last 2c: 'Fluent' seems a decent enough name. Maybe SentenceObjects - or Sent-a-Clause :)
If you guys wanna see Fluent Interface in Action, check this out
http://www.lostechies.com/blogs/joe_ocampo/archive/2007/07/02/more-fluent-interfaces-for-nunit-behave.aspx
How is the StringBuilder example not a fluent interface for its own "stringy" domain?
So expressive OOP + chaining methods == fluent interface? Or is it simply that method chaining is a construct you can employ in OOP?
I worked on jMock, the poster child for fluent interfaces before Martin got involved. We started with method chaining because I missed Smalltalk cascades but after a few generations it turned into something very different.
One of the core differences is that a Fluent Interface will guide you as to what to do next, whereas method chaining is just about less typing (a Good in itself). Programming a good Fluent Interface with a good IDE largely consists of hitting Ctrl-Space or Alt-Tab or whatever.
For all the gory details, try our OOPLSA paper at http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf
Not enough domain, and very little that actually goes beyond method chaining.
I wrote a article showing some "quick example" code illustrating how to build a Fluent Interface in C#:
http://blog.troyd.net/PermaLink,guid,5cdd4862-857a-488d-a577-c6d21b548f19.aspx
Thanks,
Troy
Comment preview